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FRAME SYNCHROlSriSATION IN THE lUB/IUR INTERFACE OF A OTRAN 

Field of the Invention 

The present mveotion relates to firame synchronisation in a radio access network and in 
particular to frame synchronisation between a Radio Network Controller and a NodeB 
of a UMTS Radio Access Network (UTRAN). 

Background to the invention 

The Third Generation Partnership Project group, known as 3GPP, is involved in 
ongoing standardisation work on the WCDMA group of protocols referred to as UMTS 
or 3G. A UMTS operator network can be separated into a number of major 
components, namely one or more core networks which are responsible for setting up 
and controlling user sessions, and a UMTS Radio Access Network (UTRAN) which 
controls access to the air interface. The architecture of a UTRAN is illustrated 
schematically in Figure 1. The interface between the UTRAN and ttie user equipment 
(UE) is provided by nodes referred to as 'TNfodeBs". The NodeBs are responsible for 
transmitting and receiving data over the air interface and are controlled by Radio 
Network Controll^ (RNCs). User and control data is routed between UEs and a core 
network via tiie NodeBs and the RNCs. The mterfitce betweai a NodeB and an RNC is 
referred to as the lub int^ace. 

There are situations in which the same data may be transmitted between a given UE and 
an RNC via two or more NodeBs. This is referred to as Diversity Handover Function 
(DUG). The NodeBs may be controlled by the same or different RNCs. In the latter 
case, data is routed to the controlling (or serving) RNC via a drift RNC. The interface 
between the serving and the drift RNC is referred to as the lur interface. Both scenarios 
are illustrated in Figure 1. 

The user-plane protocols between an RNC, NodeB, and UE are illustrated schematically 
in Figure 2. One job of fliese (UP) protocols is die implementation of a Frame 
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Synchionizadon function which takes caie of the timing of frames over the lub interfkce 
between an RNC and the associated NodeB's* An important function influencing 
Frame Synchronization is the handling of die DHO scenario in which the same frames 
are transmitted over a number of legs, some of which also may be relayed via a Drift 
RNC over the lur interface, hi the downlink direction, as the transmission over the air 
has to be synchronized, the Frame Synchronization function has to make sure that 
copies of the same frame received over different Iub*s/Iur*s with differing delays are 
received on time for sending. Figure 3 illustrates the frame synchronisation window at 
a NodeB in relation to the (DL) radio frame structure, where the time taken to process a 
frame at the NodeB is defined as Tproc. In the uplink direction, the serving RNC must 
coordinate flie receipt of identical frames received over the different Iub's/Iur*s, and 
again the Frame Synchronization function must ensure that frames are received at the 
serving RNC on time. 

Considering further (he downlink direction, a certain frame with an associated CFN 
nuniber must be transmitted over the air at a given time. If there are sev^al NodeBs 
and lub/Iur links mvolved, all NodeBs have to transmit that particular frame at the same 
time. Assuming that the delays over the lub links differ, the serving RNC must send the 
frame with a sufficient time-of^t, so that the frames are received at all transmitting 
NodeBs on time. Those NodeBs ''behind" a fast lub link must buffer die frames until 
the scheduled time for transmission. 

To supervise this function, 3GPP TS 25.402 specifies parameters defining a "Receivmg 
Wndow", which facilitates monitoring of whettier fiiunes are received eariy or late at a 
NodeB. These parameters are illustrated in Figure 3. The window serves as a 'target' 
so that ToAWS (Time of Arrival Window Start point) defines the earliest point and the 
minimum buffering c^ability needed by die NodeB, while the ToAWE (Time of 
Arrival Window End point) defines the latest 'desired' arrival time of a frame. Frames 
received during the period between ToAWE and a LtoA (Latest Time of Arrival) point 
are considered late, but not too late for transmission. Frames received after LtoA are 
discarded. The standard specifies how the NodeB shall report to the RNC in case the 
frames are received outside the widow, so that the RNC can adapt its offset accordingly: 
for each frame received outside the Receiving Window, the NodeB shall respond with a 
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•Timing Adjustment" firame, indicating the ToA (Time of Arrival) of the frame, so that 
the serving RNC can adjust its offisets. 

In order to make sure that all NodeBs receive fiames on time, the Frame 
Synchronization must be in a •*worst-case" mode, where the lub/Iur "leg" with the worst 
delay is mling the offset. A similar approach may be applied to ensure frame 
synchronisation in the iq)liiik direction. 

The standard 25.402 supports certain tools for Timing adjustment and ToA monitoring 
on the lub/Iur interfaces. One such tool simply involves trusting the "Receiving 
Window" function as described above. However, in order to receive ftequent and 
tnistworthy measurements of the frame-arrival process, it would be necessary to define 
a very narrow window such that frequent feedback from the receiving node (RNC or 
NodeB) is achieved. This is far from ideal, as to do so would generate a lot of reverse 
link traffic. With very small windows, the messages from different receiving nodes 
could also be ambiguous, with one receiving node reporting a need to reduce the ofEset, 
while another is reporting a need to increase it. In practice, a mther large window 
(based on pre-configured parameters settable by the operator) tends to be defined 
Timing adjustments are assumed to be very rare. Thus, the window-mechanism is not 
used in practice for ofGset tuning - rather it is used as a tool for recovering from fault 
evrats. Of course the result of adopting ttiis c^proach is that th^e is no means for 
actively monitoring and adapting the offset timing in real or near reattime, and the 
offset delay used for frame synchronisation is likely to unnecessarily delay the end-to- 
end transfer of data, especially during periods of relatively light loadmg of the data link 
(or a favourable transport topology). 

A second tool for determining timing adjustments involves using DL Synchronization 
Control frames. The specification 25.402 defines that flie NodeB must always respond 
to flie receipt of such a frame with a UL Synchronization Control frame including the 
value of the ToA of the DL Synchronization Control frame. However, the DL 
Synchronization Control frames can only be sent when no DL data frames are sent 
This means tiiat flie ToA monitored with this procedure does not provide a reliable 
measure of the **true*' ToA characteristics of data frames. In addition, in order to obtafai 
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high quality statistics of the ToA process, it would be necessary to perform frequent 
ToA measurements. A procedure using DL Synchronization Control ftames would 
result in excessive extra traffic in both the up- and downlink directions. For an "active'* 
connection witti a lot of traffic, it is not possible to use this function. It is noted that 
there is no standardised solution for ttie uplink direction, equivalent to this approach. 
Uplink solutions are vendor specific. 

Summary of the Invention 

The current solution for achieving frame synchronisation has a major drawback, namely 
the potential unnecessary buffering and delays in both uplink and downlink. A 
hypothesis put forward here is that different RAB types (and traffic sources) place 
different demands on the delay and on the Frame Synchronization procedure. Whilst 
current Frame Synchronization designs may be very well suited for speech, these 
designs do not necessarily provide the best possible service for Acknowledged Mode 
(AM) bearers, transporting for example data. 

Speech services belong to the "Conversational" class in terms of QoS classification. 
This QoS class has ttie most stringent delay requirements regarding delay and delay 
jittering. Speech services should be prioritised over lub interface, resulting in tight 
delay requirements for Speech. Relative to other services, the delay offsets are ttierefore 
most stringent for Speech services. Speech services are typically realised using TM 
bearers, although this need not be the case (e.g. Voice over IP). 

Speech is particularly sensitive to delay jittering, due to limited buffering in the oad-to- 
end path between the speech encoder and des©der.-^Onse-the speedi encoder-decoder 
pair is synchronized to a given (one way) delay, large jittering may cause frames to be 
lost resulting in a reduction of die subjective speech quality. It is therefore most 
important to maintain the delay and pacing of the transfer, as in the current Frame 
Synchronization solutions. The absolute delay is of less importance given the 
insensitivity of human perception to short delays (e.g. less ttian 150ms) in verbal 
communication. However, the acceptable delay variation (jitter) during a call is Umited 
to 1 ms. 
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Packet Switched (PS) bearers belonging to the Interactive or Stteaming class have 
relatively loose requirements on delay. PS bearers can flierefore be realized using the 
AM mode, in oxder to increase radio resource efficiency. Due to the non-stringent 
formal requirements on delay, the offset related to Frame Synchronization can be set to 
rather loose values. 

Due to the loose delay requirements in terms of QoS, a common misconception is to 
assume that packet-data performance is non-sensitive to delay. Indeed, packet-data 
services work also over high-latency connections, but the performance is critically 
dependent on the latency. This is particularly true for highly interactive traffic such 
Telnet, which is characterized by its request-response nature. In ttie case of gaming 
applications, it well known that players behind low-latency connections have a 
competitive edge over players experiencing long delays, hi addition, we note that also 
web-trafBc and FTP transfers suffer if ttie end-to-oid delay is high. In these cases, it is 
not only the slow response to human action that matters (as in gaming and Telnet), but 
also ttie requurements set by the TCP protocol. TCP performance is highly dependent 
on flie end-to-end delay through its congestion control mechanisms and TCP session 
setup and release procedures. 

Thus, compared to Speech services, packet data services are much less sensitive to jitter, 
but potentially more sensitive to delay. There is therefore a strong incentive to provide 
ttie lowest link latency for packet-data bearers that can be supported at any moment of 
time, even if some delay jittering would be the cost 

Accoiding to a first aspect of the present invration ttiae is provided a method of 
transporting data over ttie lub/Iur interface of a UMTS Terrestrial Radio Access 
Network, UTRAN, in which frame synchroiusation at the receiving node is achieved by 
delaying the sending of data frames from the sending node by an offset delay, the 
method comprising: 

for speech services, defiiung said offset delay as a substantially fixed delay; and 
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for data services, defining an initial offset delay and dynamically varying the 
delay at the sending node based vpon Time of Arrival feedback received from the 
receiving node, to optimise the offset delay value. 

According to a secmd aspect of the present invention there is provided a node for use in 
a UMTS Terrestrial Radio Access Network, UTRAN, the node comprising: 

means for transmitting data frames to one or more receiving nodes via lub/Iur 
interfaces with an initial timing offset; and 

means for applying dynamically varying the offset for data services based upon 
Time of Arrival feedback received from the receiving node(s), whilst maintaining the 
timing offset substantially constant for speech services. 

It is an object of the present invention to overcome or at least mitigate the disadvantages 
of known frame synchronisation techniques over the lur/Iub interfaces. This and oth^ 
objects are achieved by providing processes which enable a more continuous 
monitoring of the ToAs of frames at the receiver. 

According to a second aspect of the present invention there is provided a method of 
optimising the timing ofGsets with which data frames are transmitted over the lur/Iub 
interfaces of a UMTS TOTestrial Radio Access Network, UTRAN, the method 
comprising: 

for a given lur/Iub interface or set of lur/Iub int^aces over which identical user 
plane data is to be saoit, defining a duration of a data frame recdving window for use by 
the receiving node(s); 

transmitting data frames from a sending node with an initial timing offset; 

reducing the timing ofiGset at the sending node-in>a st^wise maimer; and 

adjusting the timing offeet at the sending node in response to the receipt of late 
Time of Arrival error reports at the sending node. 

In certain embodiments of the present invention, the initial timing offset may be set to a 
value sufiBcient to ensure a likelihood that the frames will be received at the or each 
receiving node within the defined receiving window. In oth^ embodiments, the initial 
timing offset may be set to a value short enough to ensure a likelihood that early frames 
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are received outside of that defined window, thus triggering the sending of a late Time 
of Arrival error report. 

According to a third aspect of the present invention there is provided a method of 
optimising the timing offeets with which data frames are transmitted over the lur/Iub 
interfaces of a UMTS Tarestrial Radio Access Network, UTRAN, the method 
comprising: 

for a given lur/Iub interface or set of lur/Iub interfaces over which identical user 
plane data is to be sent, defining a duration of a data ficame receiving window for use by 
the receiving node(s); 

transmittmg data frames from a sending node with an initial timing offset; 

at the or each receiving node, collecting and/or computing Time of Arrival 
statistics for received data frames; 

periodically reporting said statistics to the sending node; and 

adjusting the timing ofGset at the sending node on the basis of the received 
statistics. 

The statistics collected at a receiving node may be any suitable statistics relating to 
Times of Arrival. Preferably, these include me or more of; the mean, minimum, 
maximum, and variance of Times Of Arrival for data firames received during some time 
period, that time period typcally being the time p^od since the last statistics report 
was sent to the sending node. 

The method may comprise smding from the sending node to the or each receiving node 
instructions identifying the statistics to be collected at the receiving node and sent to the 
sending node. The instructions may identify the regularity with which the statistics 
must be sent, or events defining ^en the statistics should be sent (e.g. upon a change in 
one or more parameters). 

The method may comprise sending polling requests firam the sending node to the or 
each receiving node instructing the return of statistics. 
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The sending node may be one of a Radio Network Controller , RNC, or a NodeB. The 
or each receiving node will be the other of an RNC or NodeB. The different aspects of 
the present invention may be applied in one or both of the uplink and downlink 
directions. 

The different aspects of the present invention are particularly applicable in a Macro 
Diversity scenario, where identical user plane data is being transmitted between User 
Equipment, UE, and an RNC via two or more NodeBs. 

Adjustment of the timing offset is performed by intelligence implemented at the sending 
node. The offset may be varied using some predefined algorithm and the information 
received from the or each receiving node. 

According to a fourth aspect of the present invention there is provided a node for use in 

a UMTS Terrestrial Radio Access Network, UTRAN, the node comprising: 

means for transmitting data frames to one or more receiving nodes via lub/Iur 

interfaces wifli an uiitial timing ofGset; 

means for reducing the tuning offset in a stepwise maimer; and 

means for adjusting the timing offset in response to the receipt of late Time of 

Arrival error reports. 

According to a fifth aspect of the present invention there is provided a node for use in a 
UMTS Terrestrial Radio Access Network, UTRAN, the node comprising: 

means for transmitting data ficames to one or more receiving nodes via lub/lur 
interfaces with an initial timing of^t; and 

means for receiving statistical data sent periodically from the or each receiving 
node and relating to the Times of Arrival of data fiames at respective receiving nodes, 
and for adjusting the timing ofGset on the basis of the received statistics. 

The node of the third or fourth aspect of the present invention may be a Radio Network 
Controller or a NodeB. 
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The terminology used here to define the communications network and the radio access 
network is specific to 3G, Le. UMTS. UTRAN, and lub/Iur. However, the skilled 
person will appreciate that the present invention is also applicable to enhancements and 
successors of 3G, including 4G, whatever the terminology used in the relevant standards 
and protocols to describe equivalent components and int^aces. 

Brief Description of the Drawings 

Figure 1 illustrates schematically a UTRAN of a UMTS network; 

Figure 2 illustrates schematically the user plane protocols providing for communication 

between an RNC, NodeB, and UE of the UTRAN of Figure 1; 

Figure 3 illustrates frame synchronisation requirements at an RNC or NodeB of the 
UTRAN of Figure 1; 

Figure 4 illustrates schematically a timing offset optimisation procedure according to a 
first embodiment of the present invention; and 

Figure 5 illustrates schematically a procedure for optimising timing offsets according to 
a second embodiment of the present invention. 

Detailed Description of Certain EynhndiniertR of the Present Invention 

The comparably low sensitivity to jittering for packet switched services has made it 
possible to realize packet switched domain bearers using the Acknowledged Mode 
RLC. By itself, AM-mode typically also introduces delay jitt^ing, since SDUs 
suffering fiom transmission losses are delayed until re-transmissions repair them. In- 
sequence deliv^ further increases the traffic burstiness over the RAB egress Service 
Access Point (SAP). Burstiness is in fact an inherent feature of IP traffic, due to the 
non-existent QoS guarantees in today's IP backbone networks. In case there are some 
end-to-end requirements on the delay of the packets, as for Streaming applications, 
these requirements are typically handled by buffering before play-out 

In addition, it is noted that no strict pacing of the Frames towards the AM RLC is 
required. This is true, since the AM RLC cannot maintain any paced delivery over its 
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egress SAPs. At times of low Frame Protocol latency, the RLC round trip time (RTT) 
could be shortened, and the end-to-end perception of the s^vice would be improved. 

The requirement for setting the offset delay for fitame transmissions over the lub/Iur 
interface in the UTRAN has been discussed above with reference to Figures 1 to 3. It 
will be s^preciated that for Tninimfll end-to-end data transmission delay with rare frame 
losses, as is desirable for packet data services, it is desirable to have the frames received 
as close to the Latest Time of Arrival (LtoA) as possible (see Figure 3) with rare 
receptions in the *Too Late" region. As noted above, the existmg procedures for setting 
the ofifset delay do not provide efficient means to achieve this in an optimal way. Either 
ToA data is received by the frame sender only rarely, so that only a very prudent 
solution with excessive offsets is feasible, or it is necessary to send significant extra 
measurement traffic over the lub/Iur. 

A first preferred solution provides for an adaptive transmission offiset control method, 
by which the delay over the lub/Iur is continuously adapted to the prevailing conditions 
in the transport network. Using this method, the lowest possible delay - at any point in 
time and for any transport netwoxk topology - can in principle be achieved. The 
ToAWE limit is continuously challenged by successively (but slowly) decreasing the 
transmission ofGset at the siding node, with Timing Adjustment Frames being issued 
by the receiving node when frames are recdved after the ToAWE point. When a 
Timing Adjustment Frame is received by the siding node, the timing of£set is 
increased with an amount which is large relative to a single reduction step. 

Ihe procedure is illustrated in Hgure 4. The lowest limit of the ofiEset is continually 
probed at the sending node by decrsasing' the-o^e£-by-an amount or step a for each 
successively transmitted frame. When the lunit is hit, i.e. a first frame is received after 
ToAWE and a Timing Adjustmmt Frame received by the sending node, the offset is 
increased by a step P (where P = ka and k is a constant greats than 1). Note that the 
average number of Timing Adjustment Frames relative to the number of data frames 
can be determmed fit>m the fraction a/p. Note also that the variance of the transport 
network delay should preferably be reflected in the steps of a and p: if the delay 
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variations are very low, the method can be operated with very small steps, i.e. arriving 
at a stable operating point very close to the '^optimal" offset 

The steps a and P may be of fixed size, or one or both may be of variable size. Jn the 
latter case, the step size may be varied adaptively, depending upon feedback timing 
informaticHi recdved at the sending node from the receiving node. 

The mechanism proposed here is applicable using the Release99 version of 3G 
standards 25.402, 25.427 and 25.435. Of course the mechanism is also likely to be 
applicable to later vearsions and to other standards. 

An alternative solution to the problem of optimising frame synchronisation is to define 
and implement a measurement function at a receiving node (e.g. NodeB) which, for 
each Transport Bearer, monitors the ToA process, and reports statistics of the arrival 
process to the sending node (e.g. RNC). These statistics will typically be collected over 
some predefined time period. Based on the received statistical information, intelligence 
at the RNC will judge if there are reasons to increase or decrease the timing ofGset This 
is illustrated schematically in Figure 5. 

The statistical informaticHi of the ToA process might be any standard statistical 
information. However, usefid and easy to produce examples are the mean, minimum 
and maximum values of the ToA, and possibly the variance, over the predefined period. 
Using the received statistics, it is easy for the sending node to dedde if the timing offset 
can be reduced^ or if it must be increased. 

Based on the received ToA statistics, the receiving node may decide to trade Frame 
Handling reliability for transmission delay: If a certain proportion of frame losses is 
acceptable, the sending node may decide to set the offset so that a certain percentile of 
transmitted frames *liit" the receiving node in the 'Too Late" region. This contrasts 
with the conventional approach which is to set the offset so that frames never, or only 
very rarely (e.g. in the event of a fault) arrive in this region. 
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The statistical reporting function implemented at the receiving node shall be 
configurable by the sending node. It shall be possible to enable or disable 
measurements. It shall also be possible to define the period over which the 
measuiemrat reports are collected, and when ihey are sent. For example, the function 
may be configured such that a ToA Measurement Report shall be transmitted in the 
uplink after each block of 100 DL frames. Optionally, it shall be possible to define the 
period relative to the CFN, which is increasing irrespective of whether or not data is 
transmitted. 



